Many of today's computer software applications are written in the Java programming language. Java differs from other programming languages in that programs written in Java are generally run in a virtual machine environment. Once a Java program is written, it may then be compiled into byte-code, interpreted by the Java Virtual Machine (JVM) into hardware instructions, and executed on a variety of different platforms. This methodology allows Java to follow the “write once, run anywhere” paradigm. Components of Java programs are stored in modular components referred to as class files. A class may be defined as a collection of data and methods that operate on that data. A class is able to inherit properties (and methods) from any other class which is found above it in the hierarchy of inter-related classes for a particular program. The class located at the highest tier in the hierarchy is commonly referred to as the “parent class” or “superclass”, while an inheriting class located on a lower tier is commonly referred to as the “child class” or “subclass”.
Classloaders are a fundamental component of the Java language. A classloader is a part of the Java virtual machine (JVM) that loads classes into memory; and is the class responsible for finding and loading class files at run time. A successful Java programmer needs to understand classloaders and their behavior. Classloaders are arranged in a hierarchy with parent classloaders and child classloaders. The relationship between parent and child classloaders is analogous to the object relationship of super classes and subclasses.
The bootstrap classloader is the root of the Java classloader hierarchy. The Java virtual machine (JVM) creates the bootstrap classloader, which loads the Java development kit (JDK) internal classes and java.* packages included in the JVM. (For example, the bootstrap classloader loads java.lang.String).
The extensions classloader is a child of the bootstrap classloader. The extensions classloader loads any Java Archive (JAR) files placed in the extensions directory of the JDK. This is a convenient means to extending the JDK without adding entries to the classpath. However, anything in the extensions directory must be self-contained and can only refer to classes in the extensions directory or JDK classes.
The system classpath classloader extends the JDK extensions classloader. The system classpath classloader loads the classes from the classpath of the JVM. Application-specific classloaders (including, in the case of the BEA WebLogic product, WebLogic Server classloaders) are children of the system classpath classloader.
As used herein the term “system classloader” is used to refer to a type of classloader which is frequently referred to as an “application classloader” in contexts outside of the BEA WebLogic Server product. When discussing classloaders in WebLogic Server, the term “system” is used to differentiate those classloaders from classloaders related to J2EE applications (which BEA WebLogic typically refers to as “application classloaders”).
Classloaders typically use a delegation model when loading a class. The classloader implementation first checks to see if the requested class has already been loaded. This class verification improves performance in that the cached memory copy is used instead of repeated loading of a class from disk or permanent storage. If the class is not found in memory, the current classloader asks its parent for the class. Only if the parent cannot load the class does the classloader then attempt to load the class. If a class exists in both the parent and child classloaders, the parent version is loaded. This delegation model is followed to avoid multiple copies of the same form being loaded. Multiple copies of the same class can lead to a ClassCastException.
As mentioned above, classloaders ask their parent classloader to load a class before attempting to load the class themselves. In a product such as BEA WebLogic, classloaders that are associated with Web applications can also be configured to check locally first before asking their parent for the class. This allows Web applications to use their own versions of third-party classes, which might also be used as part of the WebLogic Server product.
At run-time, application classes are loaded into the JVM for execution by a hierarchy of one or more classloaders. This (sub)hierarchy is below the system classloader described above. The simplest design of this classloader hierarchy includes one root classloader which loads all the modules and individual class files which an application requires. However, this design is very inefficient, in that reloading a single class file or module requires the reloading of all class files or modules previously loaded by that classloader.
A second hierarchical configuration loads the majority of the class files required by the application into the root classloader and allows only web modules (commonly packaged as “.WAR” archives) to be loaded by classloaders one level subordinate to the root classloader. However, this implementation does not address the fact that the set of all modules (for example Enterprise Java Beans or EJBs) utilized by an application is still required to be loaded by a single classloader, and, therefore reloaded as a set. The problems of both of these typical hierarchical organizations include:
1. A module, for example an EJB, cannot be reloaded without reloading all classes in the application, which effectively means having to reinitialize (reinit) the entire application.
2. There is no namespace separation between modules (for example between EJB's).
A mechanism that provides more granular control over the classloader hierarchy structure and the associated interrelationships between classes would help address these problems, and give the developer better control over the reloading and namespace separation of individual modules, including EJB's.